Editing NLog
Keyfactor Command provides extensive logging for visibility and troubleshooting. For more information about troubleshooting, see Troubleshooting.
By default, Keyfactor Command outputs logging information to both the Windows event log and the local file system, places file system log files in the C:\Keyfactor\logs directory, generates file system logs at the Info logging level, and stores the primary file system logs for two days before deleting them. If you wish to change these defaults you can open the configuration file for each type of log on each Keyfactor Command server where you wish to adjust logging, and edit the file in a text editor (e.g. Notepad) using the “Run as administrator” option. Each Keyfactor component has its own NLog configuration file and NLog logging output path.
To make changes to your NLog configuration:
- On each Keyfactor Command server where you wish to adjust logging, open a text editor (e.g. Notepad) using the “Run as administrator” option.
-
In the text editor, browse to open the desired Nlog.config file for the appropriate Keyfactor component (see Table 87: NLog.config Files for Keyfactor Command). The files are located in application subdirectories under the installed directory, which is the following by default:
C:\Program Files\Keyfactor\Keyfactor Platform -
Each Nlog.config file may have a slightly different layout than the portal example shown here, but it will contain many of the fields highlighted in the below figure. The fields you may wish to edit are:
-
The path and file name of the active Keyfactor Command log file:
fileName="C:\Keyfactor\logs\Command_Portal_Log.txt"fileName="C:\Keyfactor\logs\Command_API_Log.txt"fileName="C:\Keyfactor\logs\Command_Service_Log.txt"fileName="C:\Keyfactor\logs\Command_OrchestratorsAPI_Log.txt"fileName="C:\Keyfactor\logs\Command_Configuration_Log.txt"fileName="C:\Keyfactor\logs\Command_ClaimsProxy_Log.txt"Important: If you choose to change the path for storage of the log files, you will need to create the new directory (e.g. D:\KeyfactorLogs) and grant both the service account under which the Keyfactor Command Service is running and the service account under which the IIS application pool for Keyfactor Command is running full control permissions on this directory. These roles may be served by the same service account. -
The path and file name of previous days’ log files:
archiveFileName="C:\Keyfactor\logs\Command_Portal_Log_Archive_{#}.txt"archiveFileName="c:\Keyfactor\logs\Command_API_Log_Archive_{#}.txt"archiveFileName="C:\Keyfactor\logs\Command_Service_Log_Archive_{#}.txt"archiveFileName="C:\Keyfactor\logs\Command_OrchestratorsAPI_Log_Archive_{#}.txt"archiveFileName="C:\Keyfactor\logs\Command_Configuration_Log_Archive_{#}.txt"archiveFileName="c:\Keyfactor\logs\Command_ClaimsProxy_Log_Archive_{#}.txt"Keyfactor Command rotates log files daily and names the previous files using this naming convention.
-
The path and file name of the active log file for alerting events:
fileName="C:\Keyfactor\logs\Command_Alert_Log.txt"This entry is found on in the NLog.cong files on servers with the Keyfactor Command Service installed. Info level messages are written to this log whenever alerts (certificate expiration, pending certificate request, issued certificate, denied certificate request, or revocation monitoring) are run either as scheduled tasks or as tests. The log messages include the type of alert (e.g. expiration alert), the recipient of the alert (if an email was scheduled to be sent), and the alert subject line. You can change the level of logging in the log line that references writeTo="alertlogfile". These logs are generated separately from the general events to allow for separate tracking and log shipping of alerting events. By default, the alert log filename/location for all components is the same to allow for a central source for tracking alert events across the platform.
Note: This entry is not found in NLog_Configuration.config and NLog_ClaimsProxy.config files. -
The path and file name of previous days’ Keyfactor Command log files for alert events:
archiveFileName="C:\Keyfactor\logs\Command_Alert_Log_Archive_{#}.txt"Note: This entry is not found in NLog_Configuration.config and NLog_ClaimsProxy.config files. -
The path and file name of the active log file for auditable events:
fileName="C:\Keyfactor\logs\Command_Audit_Log.txt"These logs are generated separately from the general events to allow for separate tracking of auditable events. By default, the audit log filename/location for all components is the same to allow for a central source for tracking auditable events across the platform.
Note: This entry is not found in NLog_ClaimsProxy.config files. -
The path and file name of previous days’ Keyfactor Command log files for auditable events:
archiveFileName="C:\Keyfactor\logs\Command_Audit_Log_Archive_{#}.txt"Note: This entry is not found in NLog_ClaimsProxy.config files. -
The level of log detail that should be generated for alert events and written to the alert logs:
name="EmailAlertLogger" minlevel="Info" writeTo="alertlogfile"Note: This entry is not found in NLog_Configuration.config and NLog_ClaimsProxy.config files. -
The number of archive files to retain before deletion:
maxArchiveFiles="10"This field is listed multiple times in most NLog.config files on a server with the Keyfactor Command Service installed—once for the main logging section, once for the alert logging section (if applicable), and once for the audit logging section. The default number of files to retain is 10 for the main log and the synchronization log but 14 for the alert log and audit log. The alert and audit logs are small by default, and retaining a larger number of them shouldn't create a disk space issue.
-
The maximum file size of each log file:
archiveAboveSize="52428800"Once a log file reaches this size (50 MB by default), it will be rotated to archive even if the end of the day has not been reached.
-
The level of log detail that should be generated:
name="*" minlevel="Info" writeTo="logfile"This line applies to all the logs in the file. The default Info level logs error and some informational data but at a minimal level to avoid generating large log files. For troubleshooting, it may be desirable to set the logging level to Debug or Trace. Available log levels (in order of increasing verbosity) are:
-
OFF – No logging
-
FATAL – Log severe errors that cause early termination
-
ERROR – Log severe errors and other runtime errors or unexpected conditions that may not cause early termination
-
WARN – Log errors and use of deprecated APIs, poor use of APIs, almost errors, and other runtime situations that are undesirable or unexpected but not necessarily wrong
-
INFO – Log all of the above plus runtime events (startup/shutdown)
-
DEBUG – Log all of the above plus detailed information on the flow through the system
-
TRACE – Maximum log information—this option can generate VERY large log files
-
Figure 415: Nlog_KeyfactorAPI.config
-
- Change the respective files and save your changes.
<filters defaultAction="Log">
<when condition="ends-with('${logger}', 'WebSecurityContext') and level < LogLevel.Warn" action="Ignore" />
<when condition="ends-with('${logger}', 'AlertsController') and level < LogLevel.Warn" action="Ignore" />
<when condition="ends-with('${logger}', 'CertStoreController') and level < LogLevel.Warn" action="Ignore" />
<when condition="starts-with('${logger}', 'Microsoft.') and level < LogLevel.Warn" action="Ignore" />
</filters>
You can add additional filters to remove further messages. For example, this configuration shows logs related to reading certificate templates filtered out:
<filters defaultAction="Log">
<when condition="ends-with('${logger}', 'WebSecurityContext') and level < LogLevel.Warn" action="Ignore" />
<when condition="ends-with('${logger}', 'AlertsController') and level < LogLevel.Warn" action="Ignore" />
<when condition="ends-with('${logger}', 'CertStoreController') and level < LogLevel.Warn" action="Ignore" />
<when condition="starts-with('${logger}', 'Microsoft.') and level < LogLevel.Warn" action="Ignore" />
<when condition="ends-with('${logger}', 'TemplateSecurityReader') and level < LogLevel.Error" action="Ignore" />
<when condition="ends-with('${logger}', 'CertificateTemplateReader') and level < LogLevel.Error" action="Ignore" />
</filters>
The first, for TemplateSecurityReader messages, will filter out log messages such as these:
2023-10-11 03:59:15.0183 Keyfactor.ActiveDirectory.PKI.TemplateSecurityReader [Debug] - Template: CorpWebServer
2023-10-11 03:59:15.0183 Keyfactor.ActiveDirectory.PKI.TemplateSecurityReader [Trace] - KEYEXAMPLE\jsmith (S-1-5-21-2996571167-427620427-431932065-1000) mentioned for Enroll
2023-10-11 03:59:15.0183 Keyfactor.ActiveDirectory.PKI.TemplateSecurityReader [Trace] - Access control type is 'Allow'
The second, for CertificateTemplateReader, will filter out log messages such as these:
2023-10-11 03:59:22.6312 Keyfactor.ActiveDirectory.PKI.CertificateTemplateReader [Debug] - Leaving 'Load' method with 475 certificate template objects from AD
2023-10-11 03:59:22.6312 Keyfactor.ActiveDirectory.PKI.CertificateTemplateReader [Debug] - Creating CertificateTemplate objects
2023-10-11 03:59:22.6312 Keyfactor.ActiveDirectory.PKI.CertificateTemplateReader [Trace] - Adding Certificate Template 'User'.
Both these types of messages relate to building the cache of certificate authorities, templates and permissions that Keyfactor Command uses for enrollment Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA).. These messages are specific to Microsoft templates; other types of messages are generated for EJBCA templates. The cache is rebuilt every 10 minutes, so these messages will appear every 10 minutes. If you have a large number of templates and/or users granted rights to templates in your environment, the messages can be overwhelming if you enable debug or trace logging and you don’t happen to be looking for template A certificate template defines the policies and rules that a CA uses when a request for a certificate is received. information.
Table 87: NLog.config Files for Keyfactor Command
Configuration File |
Description |
---|---|
\WebConsole\ Configuration\ NLog_ Portal. config |
The Portal file is for logging any activity to do with the Keyfactor CommandManagement Portal, including users connecting to the portal, loading various pages in the portal, and taking actions. Note: Many actions taken in the Keyfactor CommandManagement Portal are carried out using the Keyfactor API and Keyfactor is migrating the product to use the Keyfactor API more and more, so this file will have less and less activity going forward.
|
\KeyfactorAPI\ Configuration\ NLog_ KeyfactorAPI. config | The KeyfactorAPI file is the primary file for logging activity related to making requests with the Keyfactor API. Since many of the functions in the Management Portal use the Keyfactor API, this log also includes activity related to running the Management Portal. |
\Service\ Configuration\ NLog_ TimerService. config | The Timer Service file logs activity related to scheduled and automated events within Keyfactor Command such as CA synchronization, scheduled alerts, and scheduled reports. |
\WebAgentServices\ Configuration\ NLog_ Orchestrators. config | The Orchestrators, or OrchestratorsAPI, file logs activity related to Keyfactor Orchestrators API. Look here for messages related to orchestrators communicating with Keyfactor Command. |
\Configuration\ NLog_ Configuration. config | The Configuration file logs activity related to running the Keyfactor Command configuration wizard only. It may be useful to increase the logging level on this one if you are experiencing installation or upgrade issues. |
\ClaimsProxy\ Configuration\ NLog_ ClaimsProxy. config |
The ClaimsProxy file logs activity related to using Keyfactor Identity Provider for authentication. Look here for messages related to authenticating to Keyfactor Command using token authentication. Note: The ClaimsProxy log offers a further option for extended logging beyond that found for the other logs since the type of messages generated for claims-related issues tend to occur not entirely within the realm of Keyfactor Command. To configure extended logging, look in the targets section of the file for the target of type File:
Copy
Within this target, look for the reference to ${message} and modify the message structure to ${message}${newline}${microsoftconsolelayout} like so: Copy
Save the file. There is no need to perform an iisreset. Extended messages are affected by the log level setting (e.g. Info, Debug, Trace), so set this value to Debug or Trace as well for full logging. |